Fixes: #6792

Currently, by default `AbstractJmsChannel` implementations use Java serialization
for storing `Message<?>` instance into JMS destination.
The deserialized message is produced from the channel as is.
There might be use-cases when some JMS properties could be useful in downstream flows.

* Add `DefaultJmsHeaderMapper` into the `AbstractJmsChannel` as a conditional logic
to map headers to/from JMS when `jmsTemplate.getMessageConverter()` is not a `MessagingMessageConverter`.
Otherwise, then conversion of the message and header mapping is done in that converter
* Refactor logic in the `AbstractJmsChannel` to common API
* Fix Nullability formatting in the `PollableJmsChannel`
* Use lambda style for `MessageListener` in the `SubscribableJmsChannel`
instead of inner extra class
* Ensure in the `PollableJmsChannelTests` and `SubscribableJmsChannelTests`
that header mapper does it job
* Fix `JmsChannelParserTests` to not assert on the `messageBuilderFactory`
since now a `MessageListener` in the `SubscribableJmsChannel` is a direct method of the class
* Fix `JmsChannelHistoryTests` verification according to a new internal logic of the `AbstractJmsChannel`
* Document new feature in the `jms.adoc` and `whats-new.adoc`